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Deutsche Patentanmeldung 

Titel; Verfahren zum Debuggen rekonf Igurierbarer Archi- 

tekturen 

15 



Die vorliegende Erfindung befaJbt sich mit Verfahren, fur das 
Debuggen von Progratnmen auf konf igurierbaren Architekturen. 

20 Unter einer rekonfigurierbaren Archltektur, vrerden Bausteine 
(VPU) rait konf igurierbarer Funktion und/oder Vernetzung ver- 
standen, insbesondere integrierte Bauateine mit einer Mehr- 
zahl von ein- oder mehrdimensional angeordneten arithmeti-- 
schen und/oder logischen und/oder analogen und/oder spei- 

25 chernden und/oder vernetzenden Baugruppen (im Fclgenden PAEs 
genannt) und/oder kommunikativen/peripheren Baugruppen (10)/ 
die direkt oder durch ein oder mehrere Bussysteinte) miteinan- 
der verbunden sind. PAEs sind beliebiger Ausgestaltung, Mi- 
schung und Hierarchie angeordnet* Diese Anordnung wird im 

30 Wi^^iteren PAE-Array o<i©r PA genannt. 

Zur Gattung dieser Bausteine zahlen systolische Arrays, neu- 
ronale Netze, Mehrprozessor Systeme, Prozessoren mit mehreren 
Rechenwerken und/oder logischen Zellen, Vern^tzungs- und 
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.etzwer^austeine wie .-B. Crossbar-Schalte., ebenso wle be- 

.ann.e Bausteine dex Cattun. .P.^, DPS., KPU.EK, -- Hinge 

wiesen wird insbesond.re in diesem ^--"^^"^^^^/f^^'^;''',, 

,enden Schutzrechte de.salben An^elders: P 44 16 881.0-53, OE 

197 81 412,3, DE 197 81 483.2, DE 196 54 ^46.2-53, 

DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198 80 129.7, 

OE 198 61 088.2.53, DE 199 80 312.9, PC./OE 00/01B69, OE 100 

36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 

014 6, PCT/EP 00/10516, EP 01 102 674-7, PACT28, PACT26/US, 

BACT19, PACT20, PACTll- Diese sind hiermit zu Of fenbarungs- 

zwecken vollumfanglich eingeglledart . 

weiterhin soli angemerkt werden, da. die Verfahr.n auch auf 
Gruppen von mehreran Bausteinen angewendet werden kOnnan. 

BS werden mehrere Verfahr.n und Hardwareimplemantiarungen 
vorgest.llt, die ain effizientes Debuggan von VPU-Systemen 
ermdglichen, 

0 Die Aufgabe der vorliegenden Erfindung besteht daxin, Neuea 
ftir die gewerbliche Anwendung bereitzustellen. 

Die Losung der Aufgabe wird unabhangig baansprucht. Bevorzug- 
te AusfUhrungsformen befinden sich in den Onteransprtichen. 

25 

Das Dabuggen erfolgt eutweder durch dia Verwendung eines ent- 
spreohend an eina VPU angeschlcssenen Microcontroller, oder 
30 durch eine Ladelogilc nach den Patentan PACXOl, 02, 04, 05 

09, 10, 11, 13, 17, die durch Bazugnahme vollumf Snglo-ch ein- 
gegliedsrt sind. 
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Folgende grundlegenden Verfahren soUen dabei angewendet wer- 
den: 

1,1 Ezlcexmea einez Delsug-Bedingwg 
1.1.1 Bedinqunq 

Durch den Programmierer wird beispielsweise innerhalb des De- 
bug-Tools eine Oder mehrere Bedingungen festgelegt, die das 
Debugging etarten {vgl Breakpoint nach dem Stand der Tech- 
nik) . Das Auftreten der Bedingungen wird zur Lauf zeit in der 
VPO und/oder einem beliebigen mit der VPU datenaustauschenden 
Gerat festgestellt. Dies geschieht beispielsweise durch das 
Auftreten von bestiinmten Datenwerten bei bestimmten Variablen 
und/oder bestimmten Triggerwerten bei bestimmten PAEs. 

1.1.2 Vorbedincrung 

im Optimalfall kann eine bestimmte Bedingung gemSB o.g. Defi- 
nition bereits mehrere Takte vor dem Eintreffen der Debug- 
Bsdingung durch den programmierer festgelegt werden. Dadurch 
werden bestimmte Latenz-Probleme die im Folgenden diskutiert 
warden von vornherein ausgesohlosaen. 



20 



Es sollen im folgenden zwei grundlegende Arten des Debuggings 
£<lr VPUs diskutiert werden, wobei die jeweils bevorzugt anzu- 
wendende Methode von der Wahl des Compilers abhangt: 
par Compiler, die Code auf Basis von instantiierten Modulen 
25 einer Hardwarebeschreibungssprache (oder ahnlichen Sprache) 
generieren, kanii sich besonders die im Folgenden beschriebene 
Methods A eignen. 

par compiler ahnlich PACTll, die komplexe Instruktionen er- 
zeugen und nach einera VLIW-ahnlichen Verfahren generieren, 
30 eignet sich besonders die im Folgenden beachriebene Methode 
B. Grundsatzlich ist fiir den Betrieb als Prozessor oder Co- 
prozessor Methode B die bevorzugt anzuwendende- 
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E$ wurde erkannt, dass insbesondere die verwendung beider Me- 
thoden A und B gemeinsam/ zu den besten und transparentesten 
Debuggingergebnissen fUhrt. Insbesondere kann je nach Tiefe 
des zu debuggenden Fehlers zunSichst unter Zuhilfenahme der 
5 schnellen Debuggingmethode B debuggt werden und nach hinrei- 
chende Lokalisierung des Fablers sodann per Method© A die De- 
tails in der "Tiefe'' analysiert werden. 





2. Itethotde A 

10 2.x Qnindpx:xnzi.p 

Nach dem Auftreten einer (Vor) Bedingung wird die VPU angehal- 
ten. Danach werden die relevanten Debug-Inf ormationen aus den 
PASS an das Debug-Programm tibertragen. Die relevanten Debug- 
Informationen wurden zuvor durch den Programmierer innerhalb 

15 des Debug- Programmes festgelegt. Nach Auslesen aller relevan- 
ter Debug- Informationen wird der nSohste Takt ausgsfiihrt und 
erneut die relevanten Debug- Informationen ausgelesen. Diea 
wiederholt sich solange, bis der Programmierer den Debug- 
Vorgang abbricht, 

20 

2.2 Unterst'ii'bzting durdh dLLo Sardware 
2.2.1 Auslesen der Recfistex 

Wesentlich fUr die Funktionsweise des Debuggers ist die Mttg- 
lichkeit durch eine Obergeordnete Einheit {im Folgenden De- 

25 bugProzessor (DB) genannt), also beispielsweise eine CT oder 
Ladelogik, Oder einen anderen extern angeschlossenen 
(Host) Prozessor, die internen Datenregister und/oder Status- 
register und/oder Zustandsregister und ggf . je nach Implemen- 
tierung weitere relevanten Register und/oder Signale aus den 

30 PABs und/oder dem Netzwerk zurUckzulesen (zusaxnmengef afit im 
Folgenden als Debuginformation be:3eichnet) . Eine derartige 
M«3glichkeit ist z.b. mit der in PACT08/PCT geschaffenen Ver- 



4 
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bindung zwiachen der Ladelogik und dem Datenbus einer PAE 
(PACT08/PCT 0403, Fig. 4) realisierbar . 

Eb soil ausdrttcklich angemeckt sein, dal5 auch serielle Ver- 
fahren zum Auslesen der Register verwendet werden konnen. 
Beispielsweise kann JTAG gewahlt werden und der DB aber die- 
ses Verfahren ggf. auch als externes separates und evtl. auch 
niarkttibliches Gerat (z.B. Firma Hitex, Karlsruhe) angeschlos- 
sen sein. 

Da bevorzugt auf samtliche Register, Oder zumindest eine er- 
heblich Anzahl derer, durch den Debugger schreibend und/oder 
lesend zugegrif fen werden kann, kann optional und bevorzugt 
ein wesentlicher Teil der (seriellen) Verkettung der Register 
zu Testzwecken (Scan-Chain) far die Produktionstests des 
Chips etit fallen. Die Scan-Chain wird normalejrweise daftir ver- 
wendet, um alle Register innerhalb eines Chips wahrend der 
Produktionstests mit Teatdaten vorladen zu kesnnen und/oder 
die inhalte der Register zu Testzwecken wieder zuriickzulesen. 
Das Vorladen und/oder Zuraoklesen geschieht dabei typischer- 
weise durch Testsysteme (z.B. SZ Testaysteitie, Amerang) 
und/oder gemafi den in PACT09 beschriebenen Verfahren. Die 
scan-Chain benOtigt dazu einen zusatzlichen nicht unerhebli- 
chen Hardware- und FlSchenaufwand fOr jedes Register. Dieser 
kann nunmehr, zumindest ftir die Register die debugbar sind, 
entfallen, wenn - wie erf indungsgemaA vorgeschlagen - die 
25 Produktionstsstanlagen iiber gseignete Schnittstellen (z.B. 

parallel, seriell, JTAG, etc) Zugriff auf die Register erhal- 
ten. 



15 
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30 2.2.2 Anhalten Oder Verlanaaamen d es Taktes 

Ourch das Auftreten von Bedingung und/oder Vorbedingung kann 
der Takt entweder angehalten oder verlangsaiat werden, um hin- 
reichend Zeit zutft Auslesen zur VerfUgung zu stellen. Ausge- 

^- 5 
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15st wird dieser Debugbeginn entweder diirekt durch eine PAE, 
die die (Vor)Bedingung{en> berechnete oder durch eine tiberge- 
ordente Einheit (z.B. Ladelogik/CT, Hostprozessor) aufgrund 
beliebiger Aktionen, beispielsweise durch 'die Information, 

5 dafi an einer PAE eine (Vor) Bedingung auftrat und/oder durch 
eine Aktion innerhalb des DebugProzessors und/oder durch ein 
beliebiges Programm und/oder eine beliebige externe/periphere 
Quelle- Zum Informieren stehen Triggermechanismen entspre- 
chend PACTOl, PACT02, PACT08, PACTlO, PACT12, PACT17 zur Ver- 

10 f Ugung . 

Sofern der Takt verlangsaxtit wird, muss durch den Debugprozes- 
sor innerhalb des verlangsamten Zyklus des Verarbeitungstak- 
tes alle relevante Debug-Information aus den PAEs ausgelesen 
15 werden. Oazu ist es sinnvoll und bevorzugt, den Takt nur par- 
tiell zn verlangsamen, also den Arbeitstakt zu senken oder 
anzuhalten, ataer dan Takt fiir den Auslesemechanismus weiter 
fortzufahren. Desweiteren ist es sinnvoll und bevorzugt gene- 
rell die Register zum Datenerhalt mit Takt zu versorgen. 



20 



25 



30 



Nach dem Anhalten des Taktes kann ein Single-Step Modus rea- 
lisiert werden, d.h. der Debugprozessor halt den Verarbei- 
tungstakt so lange an, bis er alle Debug- Information ausgele- 
sen hat. Danach startet er den Verarbeitungstakt wieder fftr 
einen Zyklus und halt ihn erneut bis nach dem Auslesen aller 
relevanten Debug-Informationen an, 

Der Aualesetakt und der Takt des Debug-Prozessors sind bevor 
zugt unabhtngig vom Verarbeitungstakt der PAEs, sodafi die Da 
tenverarbeitung von dem Debugging und insbesondere Auslesen 
der Debug-lnformation getrennt ist. 

Hardwaretechnisch wird das Anhalten Oder Verlangsamen des 
Taktes durch Methoden nach dem Stand der Technik, wie bei- 
spielsweise Gated-Clocks und/oder PLLs und/oder Teller oder 
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andere Verfahren erreicht. Diese Mittel werden bevorzugt an 
geeigneten Stellen (Knoten) innerhalb des Clock-Trees einge- 
ftigt, sodass e±ne globale Taktsteuerungeh der jeweils tiefer- 
liegenden Zweige realisierbar ist. 

5 Besonders bevorzugt ist das Versenden einer Taktsteuer- 
Information von einer Obergeordneten Binhelt (2,B, LadeXo- 
gik/CT^ Hostprozessor) an sSmtliche PAEs. Dies kann bevorzugt 
(iber das Konf igurationsbussystem erfolgen. Die Taktsteuerin- 
formation wird typischerweise gebroadcastet Obertragen^ d,h. 

10 alle PAEs erhalten dieselbe Information, 

Beispielsweise kSnnen folgende Taktsteuerinformationen imple- 
ment iert sein: 




STOP: Der Arbeit stakt wird angehalten. 

SLOW: Der Arbeit stakt wird verlangsamt. 

STEP: Exakt ein Verarbeitungsschritt (Single Step Modus) 



wird ausgeftihrt und dann der Arbeit stakt wieder angehalten, 
STEP(n): n Verarbeitungsschritte wird ausgefOhrt und dann 
der Arbeltstakt wieder angehalten. 
GO: Der Arbeitstakt lauft normal weiter. 

20 Es soil insbesondere erwahnt sein, dass das Verfahren dor 

Taktabschaltung und/oder Verlangsamung ebenso eingeset^t wer- 
den kann,, um den Stromverbrauch zu reduzieren- Sofern tempo- 
r§r keine Rechenleistung bentttigt wird, kann ein "Sleepmode" 
beispielsweise durch das Abschalten des Arbeitstaktes (STOP) 

©25 Oder durch spezielle Befehle (SLEEP) realisiert werden. Wird 
nicht die voile Rechenleistung ben^Stigt, kann der Takt durch 
die Verwendung von SLOW verlangsamt werden und/oder temporSr 
durch STBP(n) ausgesetzt werden. Insoweit ist das Verfahren 
optional Oder zusatzXich zu den in PACT15 beschriebenen Ver- 
so fahren zur Reduzierung der Verlustleisturig einsetzbar. 

Ein Problem des Broadcastings von Taktsteuerinformationen ist 
die tibertragungszeit des Broadcastes dua:ch das Array aus 

7 
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PAEs* Die Obertragung kann bei hGheren Taktf requenzen nicht 
innerhalb eines Arbeitstaktes erfolgen- Es ist aber zwingend 
notwendig, dass samtliche PABs zur gleichen Zeit auf die 
Taktsteuerinf ormationen reagieren. Bevorzugt wird die Takt- 

5 steuerinformation daher tiber ©in gepipelintes Bussystem ahn- 
lich des in PACT17 beschriebenen "CT-Bussystems ttbertragen. 
Weiterhin wird ein Zahlenwert (LATVAL) den Taktsteuerinforma- 
tionen hinzugefUgt dar gleich oder grdUer der maximalen LSnge 
der Pipeline des Bussystems ist. In jeder Pipelinestufe wird 

10 taktweise der Zahlenwert dekrementiert (Subtraktion von 1) • 
Jede PAK die die Taktsteuerinformation erhalt dekrementiert 
im Weiteren den Zahlenwert mit jedem Takt, Damit ist sicher- 
gestellt, dass der Zahlenwert in dem gepipalinten Bussystem 
und den PAEs die die Taktsteuerinformation bereits exnpfangen 

15 haben immer exakt gleich ist, Erreicht der Zahlenwert den 

Wert 0 ist sichergestellt dass alle PAEs die Taktsteuerinfor- 
mation erhaiten haben. Jetzt tritt die Taktsteuerinformation 
in Kraft und das Verhalten des Taktes wird entsprechend mcdi- 
f iziert * 

20 Durch das beschriebene Verfahren entsteht sine weitere La- 

tenzzeit (Latency) . Diese kann beispielsweise durch die nach- 
folgend beschriebene Registerpipeline zusatzlich abgefangen 
werden oder^ wie besonders bevorzugt, durch die Definition 
der (Vor) Bedinguhg abgefangen werden, indem die 

25 {Vor)Bedingung soweit vorgesetzt wird, dass die Latenzzeit 
bereit-s berticksichtigt ist, 

Es soli besonders erwShnt werden^ dass die Latenzzeit iiu Sin- 
gle-Step Modus vernachlassigbar ist, da sie nur bei der Ab- 
schaltung es Taktes (STOP) eine Roll© spielt. Da der Befehl 
30 JSTBP iinmer nur exakt einen Schritt ausftihrt koinmt es wShrend 
des Single-Step Betriebes diirah keinerlei Verfalschung (Ver- 
25gerung) der Debugdaten durch die Latenzzeit. 



8 
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2.2,3 Re<gist:erpip^linQ zuia Ausgleichen der Latency 
Bei hOheren Betriebsf requenzen kann es zu einer Latenzzeit 
zwischen dem ErJcennen des Debugbeginns und dem Anhalten oder 
Verlangsamen des Taktes* kommen. Dies© Latenzzeit ist escakt 
vorherbestimmbar, da die Position der verzogernden Register 
in der VPD durch Hardware und/oder den zu debuggenden Algo- 
rithmus definiert und durch den Debugger daher exakt bere- 
chenbar ist. 

Durch die Latenzzeit verschieben sich jedoch die dem Debug- 
Prozessor zur VerfQgung gestellten Inf ormationen derart, daB 
nicht mehr die korrekten Debuginf ormationen ausgelesen werden 
kttnnen. Bevorzugt wird dies durch ein entsprechend^s festle- 
gen der (Vor)Bedingung durch den Prograinmierer geldst. 
Optional kann durch das Einftigen eines mehrstuf igen Register- 
pipeline, die die Debuginformation in jedem Takt um ein Regi- 
ster weiter ubertrMgt, der Debugprozessor auf soviele Takte 
an Debuginf ormationen zuruckgreif en, wie die Regis terpipeline 
lang ist. Die Lange der Registerpipeline • ist so auszulegen, 
dass sie der maximal zu erwartenden Latenz entspricht* 
Aufgrund der exakten Berechenbarkeit der Latenzzeit ist es 
nunmehr dem Debug-Programm mSglich die zeitlich korrekte re- 
levante Debug- Information aus der Registerpipeline auszule- 
sen. 

25 Ein auftretendes Problem bei der Verwendung von Registerpipe-^ 
lines ist, dass diese verhaitnismSiJig lang und damit, bezogen 
auf die ftir die Realisierung notwenige Siliziumf lache, teuer 
sind. 



15 



20 



30 



2.3 SlcshtOpare lO^bug-^XnfoCTiati.Otten 

Bei dieser Method© wird im Wesentlichen nach Auftreten der 
(Vor)Bedingung debugt, da erst danach in der Takt verlangsamt 
Oder angehalten wird und das Auslesen der Debug- in format ion 
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erfolgt* Debug-Informationen die vor dem Auftreten der 
(Vor) Bedingung liegen sind daher zun^chst nicht sichtbar. 

Es ist jedoch, wenngleich auch unter Verlust ah Arbeitslei- 
5 stxing, mdglich eine VPU sofort voin Start .einer Applikation an 
mit verlangsamten Takt Oder Single-Step-Modus zu betreiben. 
Vom Start an werden die relevanten Debug-Informationen vom 
Debug-Prozessor ausgelesen* 

10 

3. Methode B 
3.1 Grun<^ri.nsi.£» 

Relevanten Debug-Informationen aus den Speichereinheiten, die 
gemafi FACTO 1, 04, 13, 11, 18 die Anwendungsdaten und Zust^nde 
15 eines bestimmten Arbeitsschrittes beinhalten an das Debug- 
Prograrmti iibertiragen • Diese Speichereinheiten, nachfolgend 
auch Arbeit sspeicher genannt, arbeiten im Maschinenmodell 
nach PACTOl, 04, 11, 13, 18 quasi al3 Register zur Speiche- 
rung von Daten, die innerhalb eines Konf igurationszykluses im 
20 PA Oder Teilen des PAs berechnet wurden. Es wird insbesondere 
auf die Patentanmeldung PACTll verwiesen, in der die Verwen- 
dung der Speichereinheiten als Registers (REG) zur Relisie- 
rung eines Prozessormodells detailliert beschrieben ist. 
PACTll ist zu Offenbarungszwecken vollumf anglich ©ingeglie- 

©25 dert. Eine Speichereinheit besteht dabei aus einer beliebigen 
Anordung und Hierachie von unabhfingigen und abhSngigen Spei- 
chern. Es ist mOglich gleichzeitig mehrere unterschiedliche 
Algorithmen auf dem PA auszuf^ihren, die dann unterschiedliche 
Speicher verwenden. 
30 Wesentlicn fur die Anwendung dieser Methode ist/ dass Daten 
und/oder algorithmisch relevant© Zust^nde in die den PABa zu- 
geordneten Speichereinheiten abgelegt sind. Wobei eine Spei- 
chereinheit jeweils zumindest derart dimenaioniert ist/ daB 
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alle relevanten Daten und/oder Zustande eines Zyklus gespei- 
chert werden kSnnen; wobei die Lange eines Zyklus durch die 
Grafie der Speichereinhelt bestimml; sein kann und bevorzugt 
auch bestiirant ist (vgl. PACT04) . 

5 

Unterschiedliche Daten und/oder Zustande werden derart in die 
Speichereinheiten gespeichert, dafi diese eindeutlg dem Algo- 
rithmus zugeordnet werden kOnnen* Dadurch kann der Debugger 
die relevanten Daten und/oder ZustSnde (Debug-Inf ormation) 
10 eindeutig identif iaieren- 

Die relevanten Debug- Informationen kdnnen - insbesondere auch 
vorab - durch den Progranoriierer innerhalb des Debug- 
Prograinines festgelegt werden. Diese Oebug-Inf ormationen wer- 

15 den aus den Speichereinheiten ausgelesen. Dazu stehen unter- 
schiedliche Methodan zur Verftigung, ©inige Mogiichkeiten wer- 
den nachfolgend nahers beschrieben* Nach deiu Auslesen aller 
relevanter Debug- Informationen wird der nachste Konfigurati- 
ons zyklus ausgefUhrt und erneut die relevanten Debug- 

20 Informationen ausgelesen- Dies wiederholt sich solange, bis 
der Programmierer/Debugger den Debug-Vorgang abbricht. 

Mit anderen Worten, werden die relevanten Daten und/oder Sta- 
tusinformationen nicht taktweise sondern konf igurationsweise 
25 an den Debugger Ubertragen. Dies geschieht aus den Spei- 

chereinheiten/ die mit den Registern einer CPU vergleichbar 
sind. 



30 



3.2 Unterst-utzung durch die Hard.\7aa?e 

Wesentlich far die Funktionsweise des Debuggers ist die MOg- 
lichkeit durch die CT oder einen anderen extern angeschlosse- 
nen Prozessor (±m Folgenden DebugProzessor (DB) genannt) , 

U 
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die, beispielsweise auch interne (n) , Arbeitsspeicher der VPU 
2u lesen. Eine derartige Moglichkeit ist z.B. durch den An- 
schluB der CT an die Arbeitsspeicheir zum.Vorladen and Les«n 
der Daten und/oder durch die in PACT13 beschriebene Verfahren 

5 zurci Hexausschreiben der internen Speicher an externe Speicher 
gegeben. In einer mOgliche Ausgestaltung kann auf Arbeits- 
speicher durch verschieden Verfahren nach dem Stand der Tech- 
nik (Z.B. Shared Meaiory, Bank Switching) derart vora DebugPro- 
zessor zugegriffen werden, dass der Datenaustausch mit dem DB 

10 weitestgehend unabhfingig von einer weiteren Datenverarbeitung 
in der VPU erfolgen kann. 

In einer m<?giichen Ausgestaltung kann z.B. entsprechend Me- 
thode A durch eine oder mehrere der vorstehend beschriebenen 

15 MaBnahmen der Takt der VPU sum Aualeaen der Speicher gegebe- 
nenfalls entweder entsprechend verlangsamt Oder angehalten 
werden und/oder gegebenenf alls im Single-Step-Modus betrieben 
werden. Dabei kann je nach imp 1 amentia rung der Arbeitsspei- 
cher, z.B, bei Bank-Switch Verfahren auf einen besondere Bin- 

20 griff in den Takt verzichtet werden. 

Typischerweise geschieht dasAnhalten oder Verlangsamen des 
Taktes nach Methode B und das Auslesen und/oder Kopieren 
und/oder Omschalten der Arbeitsspeicher nur, wenn ein Daten- 
verarbeitungszyklua bzw. Konf igurationszyklus beendet ist. 



25 



30 



Mit anderen Worten ist ein wesentlicher Vorteil von Methode 
B, dass keine besondere Unterstatzung durch die Hardware er- 
forderlich ist. 

In einer mOglichen Ausgestaltung mufi ein DB lediglich zugrif f 
auf die Arbeitsspeicher besitzten. . . 

In einer besonders zu bevorzugenden Ausgestaltung geschieht 
der zugriff auf die Arbeitsspeicher durch eine geeignete Kon- 
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figuration der VPU, die dadurch die Arbeitsspeicher selbstan- 
dig und ohne Mbdifikation ausliest und an einen DB Obertragt. 



3.3 Zmsnxff au£ Debug- Xnfoaana-blon 

In PACTOl, PACT04, PACTll, PACT13 sind Datenverarbeitungsver- 
fahren beschrieben, bei denen zykliech eine Menge an Opera- 
tionen auf einen rekonfigurierbaren Datenverarbeitungsbau- 
stein abgebildet werden. In jedem Zyklus wird eine Mehrzahl 
von Daten berechnet, die von einer peripheren Quelle und/ Oder 
einen internen/extemen Arbeitsspeicher stanimen und an eine 
peripheren Quelle und/oder einen internen/externen Arbeits- 
speicher geschrieben werden. Dabei kOnnen jeweils unter- 
schiedliche und/oder vor allem mehrere unabhfingige Arbeits- 
15 gpeicher gleichzeitig verwendet werden. 

Beispielsweise konnen in diesem Datenverarbeitungsverfahren 
die Arbeitsspeicher Oder ein Tail der Arbeitsspeicher als Re- 
gistersatz dienen. 

Nach PACTll und PACT13 werden dabei sSmtlicha Daten und Zu- 
stande die ftir die weitere Datenverarbeitung relevant sind in 
die Arbeitsspeicher abgelegt oder aus selbigen gelesen. 
In einem bevorzugten Verfahren werden ftir die weitere Daten- 
verarbeitung irrelevante Zustande nicht gespeichert. 

25 Die Unterscheidung zwischen relevanten und irrelevanten Zu- 
standen soli an foigendem Beispiel aufgezeigt werden, es soli 
zu Offenbarungezwecken insbesondere auf die Ausfiihrungen in 
PACTll verwiesen werden s 

Die Zustandsinformation sines Vergleichs ist beispielsweise 
far die weitere Verarbeitung der Daten wesentlich, da dieser 
die auszufUhrenden Funktionen faestimmt. 

Ein sequentielle Dividierer entsteht beispielsweise durch Ab- 
bildung eines Divisionsbef ehles auf eine Hardware, die nur 

13 
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die sequentielle Division unterstutzt . Dadurch entsteht ein 
Eustand der den Rechenschritt innerhalb der Division kenn- 
zeichnet* Dieser Zustand ist irrelevant^ da far den Algoritti-- 
mu5 nur das Ergebnis (also die ausgeftihrte Division) erfor- 
5 derlich ist. In diesem Fall werden al$o lediglich das Ergeb- 
nis und die Zeit information (also die Verftigbarkeit) beniJ- 
tigt. 

Die Zeitinformation ist beispielsweise in der VPU-Technologie 
nach PACTOl, 02, 13 durch das RDY/ACK Handshake erhaitlich. 
10 Hierzu ist jedoch besonders anzumerken, dass das Handshake 

ebenfalls keine relevanten Zustand darstellt, da- es lediglich 
die GUltigkeit der Daten signalisiertr wodurch sich wiederum 
die verbleibende relevate Information auf die Existenz gtllti- 
ger Daten reduziert. 

15 

In PACTll.wird sine Unterscheidung zwischen lokal und global 
relevanten Zust^nden aufgezeigt: 

lofc^l: Der Zustand ist nur innerhalb einer einzigen abge- 
schlossen^n Konf iguration relevant, Daher mua der Zustand 
20 nicht zwingend gespeichert werden. 

global: Die Zustandsinformation wird fUr mehrere Konfigura- 
tionen benatigt* Der Zustand mufi gespeichert werden, 

Es ist nunmehr denkbar, dafi der Programmierer einen lokal re- 
25 levanten Zustand debuggen will, der nioht in den Speichern 
abgelegt ist. 

In diesem Fall kann die Applikation dahingehend modlfiziert 
werden, daft eine Debug-Konfiguration entsteht (Equivalent zum 
Debug-Code von Prozessoren) , die eine Modifikation zum "nor* 
malen" Code der Applikation derart aufweist, daJB dieser Zu- 
stand zusatzlich in die Speichereinheit geschrieben und damit 
dem Debugger zur Verfiigung gestellt wird. Dadurch entsteht 
eine Abweichung zwischen Debug-Code und tatsachlichen Code, 

14 
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die zu einem unterschiedlichen Verhalten der Codes fahren 
kann. 

In einer daher besonders bevorzugten Ausftihrung wird keine 
Debug-Konfiguration verwendet. vielmehr wird die zu debuggen 
de Konf iguration derart terminiert, dass die far Debugging- 
zwecke zusatzlich erforderlichen Daten die Terminierung uber 
dauem, d.h. weiterhin gtiltig in d©n entsprechenden Speicher 
stellen (REG) (z.B, Register, Zahler, Speicher) verbleiben. 



Eine Konf iguration wird geladen, diese verbindet die REG in 
geeigneter Weise und definierter Reihenfolge mit einem oder 
mehreren globalen Speicher (n) auf die der DB Zugriff hat 
(z,B- Arbeitsspeicher) , 
15 Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
wenden urn auf den/die giobalen Speicher zuzugreifen. 
Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
wenden um auf als Speicher ausgestaltete REG zuzugreifen. 
Entsprechend der konf igurierten Verbindung zwischen den REG 
werden die Inhalte der REG in einer definierten Reihenfolge 
in den giobalen Speicher geschrieben, wobei die jeweiligen 
Adressen von Adressgeneratoren vorgegeben werden. Der Adress 
generator generiert die Adressen fUr den/die giobalen Spei- 
cher (n) derart^ dass die beschriebenen Speicherbereiche (DE- 
25 BUGINFO) der entfernten zu debuggenden Konf iguration eindeu- 
tig zugeordnet werden konnen. 

Da3 verfahren entspricht dem Kontaxt-Switch In PACT15 und 
PACTH die zu Of f enbarungszwecken volliimf Mnglich eingeglie- 
dertp sind- 

Der DB kann nunmehr auf die Daten innerhalb eines ihm zugSng 
lichen Speicherbereiches (DEBUGINFO) zugreifen* 
Soil das Debugging mittels eines Single-Step Verfahrens 
durchgefuhrt werden^ kann nach jedem single step einer de 
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buggenden Konfiguration ein Kent ext- Switch derart durchge- 
fUhrt werden, dass samtliche Daten erhalten bleiben und di© 
zu debuggenda Information aus den REG in ©inen Arbeitsspei- 
cher geschrieben wird. Sodann wird wiederum unter Brhalt der 
5 Daten die zu dabuggende Konfiguration wieder konfiguriert und 
fQr einen weiteren single step ausgefUhrt. Dies geschieht far 
jeden zu debuggenden single step, der zu debuggenden Konfigu- 
ration* 

10 

3.4 Sichtbare t)ebug'*Xn£orniati.onen 

Ein Debuggen vor der (Vor) Bedingung kann vergleichsweise ein- 
fach und ohne grofle Perf ormance-Verluste durchgefahrt werden, 
da die benGtigten Debug-Inf ormationen in Arboitsspeicher ver- 

15 fiigbar aind. Durch das Ubertragen der Arbeitsspeicher in an- 
dare Speicherbereiche^ auf die der DB bevorzugt direkten 2u- 
griff hat, kann die Debug-Inf orxnation einfach sichergestellt 
werden. Eine noch schnellere Methode ist, die Arbeitsspeicher 
durch ein Bank-Switching Verfahren (nach dem Stand der Tech- 

20 nik) derart zwischen den einzelnen Konf igurationen xomzuschal- 
ten, dafi die Debug-Information in einer jeweils neuen Bank 
liegt. Das Umschalten kann sehr zeitoptimierend, im Optimal- ' 
fall sogar ohne Auswirkung auf die Verarbeitungsleiatung er- 
folgen* 

25 



4. Fmxkiiiongxyeige das Debuggers 

30 Das Debugger Programm selbst kann auf einem DB aufierhalb des 
PA'S ablaufen, Alternativ dazu kann eine VPU selbst den DB 
darstellen^ entsprechend der -Methoden, die bei Prozessoren 
angewendet werden, Dazu kann ein Task- oder Kontextswitch 
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(SWITCH) entsprechend den Ausftthrungen in PACTII ausgefilhrt 
werden. Die Debuginformationen des zu debuggenden Programmes 
weirden bei ©inem SWITCH zusammen mit den relevanten Daten ge-* 
sichert und das Debugger Progratnm geladen^ das die informa- 

5 tionen auswertet und/dder Interaktiv mit- dem Programmierer 
verarbeitet. Danach wird erneut ein SWITCH durchgefUhrt (bei 
welchem die relevanten Informationen des Debuggers gesichert 
werden) und das zu debuggende Prograinm wird weitergef iihrt . 
Die Debug-Information wird von Debugger entsprechend Methode 

10 A und/oder B gelesen und in einen von der Datenverarbeitung 
separaten Speicher und/oder Speicherbereich gespeichert, auf 
den der DB bevorzugt direkten Zugriff besitzt. 
Durch das Debugger-Programm werden die Breakpoints und 
(Vor) Bedingungen definiert. Ebenfalls kann das Debugger- 

15 Programm die Kontrolle iiber die Ausftihrung der Applikation, 
insbesondere den Ausfuhrungs start und das Ausf ahrungende 
ubernehmen, . 

Der Debugger stellt dem Programmierer eine geeignete Arbeit- 
sumgebung zur Verftigung mit ggf. graphischer Oberflache* In 

20 einer besonder bevorzugten AusfUhrung ist der Debugger in ei- 
ne komplexe Entwicklungsumgebung integriert und tauscht mit 
dieser Daten und/oder Steuerinformation aus, Insbesondere 
kann der Debugger die aus den Arbeitsspeichern gelesenen Da- 
ten zur beliebigen Weiterverarbeitung auf einen DatentrSlger 

25 (Pestpiatte, CDROM) speichern und/oder innerhalb eines Netz- 
werkes (Ethernet) ablaufen*' 

Der erfindungsgemafte Debugger kann zudem gemSiO PACT20 inner- 
halb einer Entwicklungsumgebung mit anderen Werkzeugen und 
insbesondere auch Debuggern kommunizieren; wobei in einer be- 
30 vorzugten Ausgestaltung die Steuerung und/oder Definition der 
Debugparamater von einem anderen Debugger aus (ibernommen wer- 
den kann. Ebenso kann der Debugger die von ihm generierte De- 
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bug-Information elnem anderen Debugger zur VerfUgung stellen 
und/oder von diesem dessen Debug-lnformation erhalten. 
Insbesondere das Feststellen des Auftretens von Breakpoints 
und/oder {Vor)Bedingung i$t durch einen anderen Debugger aus,, 
5 bzw. den Einheiten die dieser andere Debugger debugtr durcti- 
fahrbar. Der erf indungsgemafie Debugger und die VPU reagieren 
dann entsprechend. 

Der andere Debugger kann insbesondere der Debugger eines ei- 
ner VPU zugeordneten anderen Prozessors sein. 
10 Der andere Debugger kann insbesondere der Debugger eines mit 
einer VPU gekoppelten anderen Prozessors (CT, bzw. ARC bei 
Chameleon) sein. 

Insbesondere kann der andere Debugger auf einem der VPU zuge- 
ordneten und/oder gekoppelten Prozessor ablaufen und/oder der 
15 zugeordnete Prozessor der DB sein, beispielsweise elne CT^ 

b2:w. ARC bei Chameleon- In einer besonders bevorzugten Ausge- 
staltung kann der zugeordnete Prozessor ein Host-Prozessor 
sein, wie beispielsweise in PACT26/US und/oder PACT28 be- 
schrieben. 



20 




25 



30 



S. Bewer-fctmq der Mtethoden 

Die Methode A ist erheblich zeit- und ressourcenintensiver 
als die Methode B, bei der kaiim zus^tzliche Hardware erfor- 
derlich ist und zudem ggf . das zeitaufwendige Auslesen der 
Debug-Information vom Start der Applikation an entfMllt. Da- 
her ist Methode B grundsStzlich vorzuziehen. Fiir Compiler 
nach PACTH ist die Methode B eindeutig zu praferieren. 
Es wurde erkannt, dass insbesondere die Verwendung beider Me- 
thoden A und B gemeinsara^ zu den besten und transparentesten 
Debugging^rgebnissen fahrt. Insbesondere kann je nach Tiefe 
des 2u debuggenden Fehlers zunSchst unter Zuhilfenahme der 
schnellen Debuggingraethode B debuggt werden und nach hinrei- 
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chende Lokalisierung des Fehlers sodann per Methode A die De- 
tails in der "Tiefe" analysiert werden, 



5 6. Mined Mtode P^ttacfer 

Bei der Anwendung der besonders bevorzugten Methode B kann es 

zu dem Problem kommen, dass die in den Speichern befindliche 

sichtbare Information nicht hinreichend ist, 

Typischerweise kann ein detaillierteres Debugging folgender- 
10 massen erfolgen: 

a) Die sichtbare Debuginformation (PREINPO) vor der Konfigu- 
ration. einer einen Breakpoint enthaltenden Konfiguration wird 
gesichert. Bei Auftreten eines Fehlers bei dem Breakpoint 
vird die dann sichtbare Debuginformation (POSTINFO) gesi- 

15 chert. Basierend auf der PREINFO Information wird ein Soft- 
ware-Simulator gestartetdie zu debuggende (n) Konfigurati- 
on (en), simuliert. Der Simulator kann dabei jeden Wert inner- 
halb der PAEs und der Bu3sy3teme bestimmen und (ggf- auch 
graphisch und/oder textuell) ausgeben, wodurch ein detail- 
lierter Einblick in den Ablauf des Algorithmus zum Zeitpunkt 
des Auftretens dee Fehlers erreicht wird. Insbesondere ist es 
mttglich die jeweils simulierten Werte mit den Werten von PO- 
STINFO zu vergleichen urn Differenzen schnell zu erkennen. 

b) Die slohtbare Debuginformation vor einem Breakpoint wird 
gesichert. Bei Auftreten eines Breakpoints wird basierend auf 
dieser Information ein Software-Visualisierer gestartet. Der 
zu debuggende Baustein wird nunmehr in einem Single-Step Ver- 
fahren betrieben, das. das Auslesen sSmtlicher relevanter Da- 
ten nach Methode A ermCglicht. Diese Daten kdnnen nunmehr 
entweder direkt (ggf. auch graphisch und/oder textuell) aus- 
gegeben werden und/oder an einen Simulator weitergeleitet 
werden, dessen Simulation sodann auf den detaillierten Daten 
beruht, und danach wie bekannt ausgegeben werden* 

19 
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6«X Vox^'to±Xe ei.nes Mixed Mode Debuggers . 

Der Mixed Mode Debugger erm5glicht die detaillierte Analyse 

5 der Abiaufe innerhalb eines Bausteines* Durch die MGglichJceit: 
gem^fi Methode B bis zu einem gesetzten Breakpoints mit voller 
Geschwindigkeit zu arbeiten und danach ggf . anzuhalten 
und/oder ggf ♦ in einen Single-Step Modus zu gehen, wird das 
Debugging zeitef f izient, wodurch das Testen grofier Datenmen*- 

10 gen und/oder komplexer Algorithmen ermOglicht wird. 

Das bevorzugte Aufsetzen eines Simulators nach dem Auftreten 
des Breakpoints auf Basis der aktuellen Daten und Zustande 
ermoglicht einen genauen Einblick in die Hardware. Sofern der 
Zeitaufwand ftir die Simulation zu hoch ist und/oder die 100% 

15 Ubereinstixnmung des Simulators mit der Hardware fraglich ist,. 
ermOglicht das Zurticklesen von Daten im Single-Step Modus 
nach Auftreten eines Breakpoints gem^Ji Methode A oder ent- 
sprechend des Kontext-Switch Verfahrens nach PACT15 und 
PACTll ein 100% korrektes Debugging des Algorithmus und/oder 

20 auch der Hardware selbst« 



7, Beaohrexbianq der Fiqiiren 

Figur 1 und 2 entsprechen der Patentanmeldung PACTll. Die un- 
25 terschiedlichen Anaatze der Methoden A und B wurden in die 
Figuren eingezeichnet (A, B) 



Figxii: lb zeigt eine Representation des endlichen Automaten 
30 durch eine rekonf igurierbare Architektur nach PACTOl und 

PACT04 (PACT04 Fig. 12-15) . Das kombinatorischen Netz aus Fi- 
gur la (0101) wird durch eine Anordnung von PAEs 0107 ersetzt 
(0101b) . Das Register (0102) wird durch einen Speicher 

20 
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(0102b) ausgefUhrt, der mehrere Zyklen speichern kann. Die 
RUckkopplang gemSiJ 0105 erfplgt durch 0105b. Die EingSnge 
(0103b bzw. 0104b) sind aquivalent 0103 bzw 0104. Der direkte 
Zugriff auf 0102b kann ggf- durch einen Bus durch das Array 
5 0101b realisiert werderi. Der Ausgang 0106b ist wiederum Equi- 
valent 0106. 

Fx^ur 2 zeigt die Abbildung eines endlichen Automaten auf ei- 
ne rekonf igurierbare Architektur . 0201 (x) reprSsentieren das 
kombinatorische Netz (das entsprechend Figur lb als PAEs aus- 
gestaltet sein kann) . Es existiert ein oder mehrere Speicher 
fUr Operanden (0202) und ein oder mehrere Speicher fiir Ergeb- 
nlsae (0203) • 2;u5atzlich Oaten Ein-/Ausgange gem. 0103b, 
0104b, 0106b) sind der Einfachheit haiber nicht dargestellt. 
Den Speichern zugeordnet ist jeweils ein Adressgenerator 
(0204, 0205) - 

Die Operanden- und Ergebnisspeicher (0202, 0203) sind physi- 
kalisch oder virtuell derart miteinander verkoppelt/ daB bei- 
spielsweise die Ergebisse einer Funktion einer anderen als 
Operanden dienen k5nnen und/oder Ergebnisse und Operanden ei- 
ner Punktion einer anderen als Operanden dienen k5nnen. Eine 
derartige Kopplung kann beispielsweise durch Bussysteme her- 
gestellt werden oder durch eine (Re) Konf iguration durch wel- 
ch© die Funktion und Vernetzung der Speicher mit den 0201 neu 
konfiguriert wird. 

Figur 3 zeigt eine magliche achematische Struktur des Debug- 
so gings nach Methode Bs sei insbesondeire beispielhaft auf 
die Figuren 19, 20, 21 der Patentanmaldung PACT13 verwiesen, 
in welcher die Grundlage der Speicher beschrieben ist. PACT13 
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wir hiermit zu Off enbarungszwecken volliamf anglich eingeglie- 
dert • 

0101b und 0102b ist wis bereits beschrieben dargestellt. Zu- 
satzlich ist sine externer Speichereinheit dargestellt 

5 (0302)/ der mtiglichexweise ahnlich PACT13 an 0102b anga- 
schlossen (0307) sein kann. Bs soli besonders darauf hinge- 
wiesen werden, dafi sowohl 0102b als auch 0302 extern© oder 
interne Speicherdinheiten sein k5nnen. Ebenfalls soil eine 
Speichereinheit als mindestes ein Register, eine Menge von 

10 Registern oder ein Speicher (RAM, Flash, o.a.) oder Massen- 
speioher (Festplatte, Band, o.a«) definiert sein. 

Die debuggende Einheit 0301 kann Breakpoints innerhalb 0101b 
setzen (0303), auf Basis derer der eigentlich© Debug Vorgang 

15 ausgeiast wird. Durch das Erreichen eines Breakpoints wird 
eine Information (0304) an 0301 gesendet, die den Debug Vor- 
gang startet; zugleicb werden auch alle 0101b interenen Vor- 
kehrungen zum Debuggen (2*3* ein Anhalten und/oder Verlangsa- 
men des Taktes) ausgel^st. Alternativ kann auch durch 0301 

20 die Information generiert und an 01 01b gesendet werden, 

tJber 0305 und/oder 0306 kann 0301 auf die Daten und/oder Zu- 
stclnde aus dem Speicher 0102b und/oder dem- Speicher 0302 zu- 
greifen. Der Zugriff kann zum Beispiel 

1. durch eine Speicherkopplung (Block-Move, d.h. kopieren 

25 der Speicher in einen anderen, von 0301 kontrollierten 

Bereich) 

2« durch eine Leitung (serielle oder parallele Leitung, 
tiber die ein oder mehrere Speicherbereich (e) libertragen 
wird/ werden, z.B. JTAG) 
30 3. Buskopplungen gleich welcher Art (die Speicher werden 

ahnlich eines DMA-Verf ahren arbitriert und von 0301 ver- 
arbeitet) 
erfolgen- 

22 
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Als Beispiel wurde eine Figur aus PACT13 gewahlt. Es soil 
ausdriicklich darauf hingewiesen werddri/ daB grundlegen<^ jedes 
Speicherverfahren und jede Speicherkopplung (Stack, Random- 
5 Access, FIFO/ usw,) entsprechend bearbeitet warden kann. 

Die Figuren 4a und 4b aeigen weitere mOglichen Ausgestaltun- 
gen und warden aus dor Patentanmeldung PACT28 entnonunen, die 
zu Of f enbarungszwecken voUumf anglich eingegliedert . ist . 

10 Der Aufbau einer besonders bavorzugten VPU ist in Figur 4a 

dargestellt. Vorzugswelse hierarchische Konf igurationsmanager 
(CT's) (0401) stau^rn und verwalten eine Anordnung von rekon- 
f igurierbaren Elementen (PACs) (0402). Den CT's ist ein Ipka-- 
ler Speicher fiir die Konfigurationen zugeordnet (0403) • Der 

15 Speicher verfiigt weiterhin (Iber ein Interface (0404) zu eineiti 
globalen Speicher^ der die Konf igurationsdaten zur VerfUgung 
stellt. Ober ein Interface (0405) sind die Konf igurationsab- 
lauft steuerbar. Ein Interface der re konf igurierbaren Blemen- 
te (0402) zur Ablauf steuerung und Ereignisverwaltung (0406) 

20 ist vorhanden, ebenso ein Interface zum Datenaustauach 

(0407) . Beipielsweise kann eine der CT's als DB agieren. 

Figur 4b zeigt einen Ausschnitt aus einem beispielhaf ten CPU 
System^ beispielsweise einem DSP des Types C6000 von Texas 

25 Instruments (0451)* Dargestellt sind Prograramspeicher (0452) ^ 
Datenspeicher (0453), beliebige Peripherie (04S4) und EMIF 
(0435) . Ober einen Speicherbus (0456) und einem Peripheriebus 
(0457) ist eine VPU als Coprozessor integriert (0458), Ein 
OWA-Kontroller (EDMA) (04 59) kann beliebige DMA-Transfers, 

30 beispielsweise zwischen Speicher (0453) und VPU (0458) Oder 
Speicher (0453) und Peripherie (0454) durchfUhren. In diesem 
Beispiel kann 0451 als DB arbeiten und insbesondere auch der 
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erf indungsgemafie Debugger mit dessem Debugger gekoppelt 
und/oder in diesen integriert sein. 

Flgur 5a zeigt einen beispielhaften Hardwareaufbau, der zum 
5 Debuggen von rekonf igurierbaren Prozessoren benutzt werden 
kann. Hierzu wird ©in gepipelinter Konf igurationsbus 0501 
verwendet/ Shnlioh dem aus PACT17 bekannten. Die Pipeline ist 
tiber mehrere Registerstufen (0502) in horizontaler und/oder 
vertikaler Richtung aufgebaut^ um hOhere Taktf requenzen zu 
10 erreichen. Der gepipelinte Konf igurationsbus fUhrt zu den zu 
konfigurierenden Elementen (PAEs) (0503), um diese mit.Konfi- 
gurationsdaten zu versorgen, 

Figtir 5b zeigt beispielshaf t die erf orderliche Erweiterung 
15 gem^A der vorliegenden Erfindung, Jede Registerstuf e (0502) 
dekrementiert den Zahlenwert (LATVAL) zum Ausgleich der La- 
tenzzeit um 1 (angedeutet durch -1) . Ebenso dekrementiert je- 
de PAE (0503), die bereits eine Taktsteuerinformation erhal- 
ten hat, diese pro Takt um 1 (angedeutet durch -1/T) , Auf die 
20 PAEs und insbesondere deren internen Register kann nunmehr 
nicht nur schreibend sondern auch lesend zugegriffen werden, 
z.B. aber eine besondere Steuerleitung (RD) , um Debugdaten 
auszulesen. Zu schreibende und gelesene Daten durchlaufen in 
diesem Beispiel das Bussystem durch das Array aus PAEs von 
25 links nach rechts und in der untersten Zeile in RUck- 

wartsrichtung. Der Konf igurationsbus ist weiterhin Uber Regi- 
sterstufen (0505) pipelineartig zurllckgeftthrt (0504) . In die- 
sem Beispiel kann eine Ubergeordnete Binheit (CT/Ladelogik/ 
Hostprozessor) (0506) ebenso lesend und schreibend auf den 
Bus zugreifelfi, wie ein dediziertes Testinterf ace (0507) . Das 
Testinterface kann einen eigenen Testkontroller aufweisen und 
insbesondere kompatibel zu einem oder mehrern marktgSngigen 
Testschnittstellen sein (z-B. JTAG, Tektronix, Rhode SSchwarz, 

24 



30 
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Q 



etc) . Die Auswahl der bussteuernden Einheit erfolgt iiber eine 
Multiplexer/Demultiplexer-Einheit (0508) • In (0509 in Klaiti- 
mern und kursiv dargestellt) oder vor deh Einheiten 0506 und 
0507 kann eine Schaltung zur Rackrechung der Herkunftsadresse 
5 (0509) von Debugdaten/ die Uber 0504 eintreffen, vorgesehen 
sein. Die Adressberechnungen innerhalb des aufgezeigten Sy- 
stems geschehen wie folgt: Zunachst wird die Adresse durch 

0506 Oder 0507 am Bus 0501 angelegt. Die Adresse wird Shnlich 
der Verarbeitung der Zahlenwerte (LATVAL) zur Latenzberech- 

10 nung in jeder Registerstufe (0502 und 0505) dekrementiert- 
Sobald die Adresse gleich 0 ist,' wird die nach der Register- 
stufe liegande PAE selektiert. In der nachf olgenden Register- 
stufe wird die Adresse negativ, sodass keine weiteren PAEs 
mehr aktiviert werden. Sofern Oaten aus einer PAE gelesen 

IS werden, werden diese zusammen mit der Adresse zuruckabertra- 
gen. Die Adresse wird dabei in jeder Registerstuf e weiter de- 
krementiert, Eine RUckrechnung in 0509 der bei 0506 und/oder 

0507 zusammen mit den Debugdaten eintref f enden Adressen ist 
nunmehr durch eine einfache Addition mdglich;. indem die An- 

20 zahl der dekrementierenden Registerstuf en zu dem eintreffen- 
den Adresswert hinzuaddiert werden. Es soli angemerkt sein, 
dass die Registerstufen 0S02 in Figur 5b leicht unterschied- 
lich gegentUoer den Registerstufen 0502 in Figur 5a ausgestal- 
tet sind. In Figur 5b weisen diese namlich zusatzlich eine 

25 Schaltung (z.B. Multiplexer) zu Auswahl der weiterzuleit enden 
Daten auf , der entweder .die Daten des Busses 0501 weiter- 
schaltet oder den Ausgang der zugeordneten PAE (0503) und so- 
mit die DebugDaten. Zur Ansteuerung der Schaltung kann das 
Auftreffen des Adresswertes gleich 0 dienen. 



30 



Es wird nochmals darauf hingewiesen, dass das dedizierte Te- 
stinterface (0507) den Industriestandards entspricht. Es kann 
zu Tests wahrend des Software-Debug -Vorgangs eingesetzt wer- 

25 
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den und/oder zu Test wShrend des Zusammenbaua von Hardware- 
komponenten und -syatemen (z.B. dem Zusaflimenbau der Schaltun- 
gen auf der Platine) und/oder zu Funktionstests des Halblei- 
terbausteins (Chips) im Rahmen der Halbleiterfertigung. Ins- 
5 besondere dadurch kann. die tibliche Scan-Chain z\m Test der 
Register wShrend des Funktionstests des Halbleiters entfallen 
Oder zumindest entsprechend minimiert werden, da dann nur die 
Register durch die Scan-Chain gefUhrt werden mUssen, die 
nicht vom Bussystem (0501) ansteuerbar sind* 

10 

Ebenfalls wird besonders darauf hingewiesen, dass das in Fi- 
gur 5 erl^uterte Verfahren keinesfalls auf die Anwendung von 
Konf igurationsbussen beschr^nkt ist. Gewohnliche Datenbussy- 
steme k5nnen ebenso zu den unterschiedlichen vorab aufgezahl- 
15 ten Test- und Debugging- Zeitpunkt en und -arten verwendet wer- 
den. Insbesondere sei in diesem Zusatmtienhang auf das in 
PACT07 beschriebene Datenbus system hingewiesen, PACT07 ist 
hierzu zu Of fenbarungszwecken vollumfSnglich eingegliedert « 
Die in Figur 5 beschriebenen Verfahren k5nnen, filr einen In- 
20 genieur mit gew5hnlichen technischen Kenntnissen leicht nach- 
vollziehbar ebenso auf PACT07 angewendet werden. 
Ein Mischbetrieb unterschiedlicher Bussysteiuer wie Konfigura- 
tionsbussysteraen;. Datenbussystemen nach PACT07 und gewOhnli- 
chen Datenbussystemen ist desweiteren grundsatzlich mSglich. 
25 Dazu kannen mehrere Test inter face vorgesehen sein, Oder wie 

©technisch bevorzugt die Mult iplexer /Demultiplexer stufe (0508) 
auf eine Mehrzahl von Bussystemen (n x 0501/ n x 0504) ausge- 
legt werden* 



30 Abschlieftend soil noch besonders erwahnt sein, dass durch die 
. Ruckftihrung des Bus systems nach Figur 5ta auch die in die PAEs 
zu schreibenden Konf igurationsdaten zur\ickgeftihrt werden. Un- 
ter Zuhilfenahme der AdressrUckrechung (0509) und der zurtick- 

26 
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gefUhrten Statusleitung REJ, die nach PACT17, PACTIO, PACT05 
eine Zurackweisung der Konf igurationsdaten anzaigt/ kann auf 
di© Verwendung der Konf igurationszwischenspeicher-FIFOs nach 
PACT17 Figuren 8 und 9 (0805, 0903) verzichtet werden^ da da- 
5 ran Funktionalitfit nurimehr vollumfanglich Qber das beschrie- 
bene Bussystem abgebildet wird* 
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XokaJ. reXevan-tor Zustand Zustand der nur Innerhalb einer 

bestimmten Konfiguration relevant ist 

5 

global relevantsr Zustand Zustand der in inehreren Konfi- 
gurationen relevant ist .und zwischen don Konf igurationen aus-- 
getauscht werden mufi 

10 relevanter Zustand Zustand der innerhalb eines Algo- 

rithmus zur korrekten Ausfuhrung dessen bendtigt wird und so- 
mit durch den Algorithmus beschrieben ist und verwendet wird 




xrrelevanter Zustand Zustand der fur den eigentlichen Al- 



ls gorithmus ohne Bedeutung ist und auch nicht im Algorithmus 
beschrieben ist, der jedoch von der ausfQhrenden Hardware im- 
plementierungsabhangig benotigt wird 



2S 
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Verfahren zum Debuggen rekonf igurierbarer Archi-- 



15 tekturen 

Patentansprtiche 

20 Verfahren zum Debuggen von rekonfigurierbarer Hardware^ da- 
durch gekennaeichnet/ dal^ sSmtliche notwendige Debuginforma- 
tion je Konfigurationszyklus in einen Spelcher geschrieben 
werden, der dann vom Debugger ausgewertet wird. 
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